GPAL.Form builds a GUI that belongs to your workflow -- a window you design, with controls you place. GPAL.Application automates someone else's GUI -- a window that already exists, with controls you locate. They share a vocabulary (buttons, inputs, checkboxes) but solve opposite problems.
Show displays a form without pausing the workflow, ShowDialog pauses execution until the form closes, and Hide closes it. Choosing between them determines whether the form is a blocking prompt or a live status window.
A GPALForm is a real Windows form, so the rules of a Windows form apply: the window is drawn on one thread, and a workflow that runs on that thread freezes it. GPAL marshals every control call for you. What is left to you is saying which thread the handler itself runs on, which is one method on the button.
Every GPAL form control -- button, checkbox, input, combo box, grid, chart, and the rest -- is built the same way: a fluent chain of With... Settings, completed with a cast to the control's type -- for example, Input -- and handed to WithFormControl. Learn the pattern once and every control type follows it.
A GPAL form isn't limited to one screen of static controls. FillInFrom can drive the same form through every row of a grid, file, or database query, with CallAfterFillIn running your logic between rows.
GPALTab creates a new tabbed container directly in the WithFormControl chain. Each tab control passed creates a new tab and controls added after it go into that tab until the next tab control is added. Similarly, GPAL.Splitter is a container holding two panes: add the controls of both in order and mark where the first ends with GPAL.SplitRight, or GPAL.SplitBottom for a top and bottom split. Both compose freely: a split inside a tab or a tab inside a split is just a matter of order in the chain.